The present invention relates to communication systems. More particularly, and not by way of limitation, the present invention is directed to a Session Initiation Protocol (SIP)-based Call Session Server and a method of routing messages within the server.
A resilient, distributed, and load-balanced SIP-based Call Session Server, such as a high capacity IP Multimedia Subsystem IMS-CSCF node, may implement a Call Session Control Function (CSCF). The server is designed to handle many simultaneous one-to-one calls and conference calls, while providing its services via only one or a few advertised external interfaces (for example the SIP standard port 5060 and a few designated IP addresses). The CSCF creates multiple Back-to-Back User Agent (B2BUA) instances on possibly multiple processor elements for handling the calls simultaneously, and is typically designed to process not only calls conforming to the standard SIP protocol (RFC3261), but also calls based on variants and/or extensions of the RFC3261 standard, some of which may be proprietary. The CSCF may also need to simultaneously (within the same call session) support a combination of pure RFC3261 calls and calls based on multiple variants and/or extensions of RFC3261. The CSCF may also use a SIP-based protocol for controlling call-related resources. For example, a CSCF acting as a media gateway controller can control the media resources in a multi-media gateway/server using a SIP-based protocol.
When multiple B2BUA instances are created on multiple processor elements behind a limited set of external interfaces to handle multiple simultaneous calls, signaling messages coming in from external nodes must be correlated and routed to the correct B2BUA instance for each call. In order to achieve this, the CSCF usually implements a call-session-aware SIP message routing framework. That is, for every call, the SIP message routing framework must share all of the call session information (such as the values of message parameters generated by a B2BUA instance) with the corresponding B2BUA instance.
The existing solutions for SIP message routing in the typical implementations of the Call Session Server's CSCF functions rely on the “Call-ID”, the “branch”, and/or the “tag” parameters in the SIP protocol message headers. RFC3261 requires these parameters to be to be random and unique in length, space, and time. When one gateway generates these parameters for outgoing requests, the remote/peer gateways involved in the call session are required to echo them back in some form in the incoming responses to the Call Session Server.
A typical CSCF generates various SIP message parameters such as the Call-ID, branch, and tag parameters as arbitrary strings of arbitrary lengths, so that they are unique and random in space and time, and across multiple calls. However, due to the nature of the generation process and randomness of the various parameters, they usually do not have any distinctive properties or patterns that can be used by the message-routing framework to correlate the messages with the call sessions and determine the corresponding B2BUA instance within the CSCF to which the message is to be routed. Therefore, in order to aid the routing framework in correlating and routing the SIP messages, the various parameters generated for every call session by its B2BUA instance are shared with the SIP message-routing framework. However, the values of the various parameters of a call session might have little or no correlation with each other. Moreover, the existence and values of the parameters also depend on the state of the call session in the state-machine, which can be call-leg specific, and whether a call-leg is compliant with the pure RFC3261 or a variant/extension thereof. Therefore, in order to utilize the parameter values effectively to correlate and route the messages, common substrings are incorporated into the parameter values across multiple headers, and the call state information is also shared between the B2BUA and routing layer.
The information sharing between the B2BUA instances and the routing framework is typically done using Inter-process Communication (IPC) mechanisms and/or a distributed database. At the routing framework, the use of the database also provides resiliency, fault tolerance, and load balancing with the parameters of the call sessions inserted into call session records and checked into the distributed database, which is replicated across all processors in the node (also known as total replication). The routing framework is designed to consist of multiple routing process instances, with redundancy, spread across multiple processor elements. The B2BUA instances and the routing framework store and retrieve the call session records from the database on any processor.
The use of common substrings in the parameter values and information sharing between the B2BUA instances and the SIP message routing framework, when attempting to make the routing framework call-session-aware, present significant design problems. The problems fall into three main categories. First, the procedures lead to inefficiencies in both the B2BUA layer and the routing framework within the CSCF due to the significant overhead and complexity of call session information sharing and maintenance between the two layers. Second, since the routing framework is forced to maintain the call session information for every call (for resiliency, fault tolerance, and load balancing), if one instance of the routing process crashes, the session information of all the affected call sessions must be moved to another routing process, possibly on another processor element. This also involves saving and retrieving the call session information of the affected calls in a distributed database. However, this incurs a significant overhead and cost in routing process management and database management in the signaling plane. In addition, when a failure occurs in the routing framework, the B2BUA instances of the affected call sessions must be re-associated with the new routing process instances, and there is additional overhead incurred for managing the associations. This wastes processor and memory resources and increases the call processing latency, negatively impacting the performance and capacity of the system, while making the overall design of the CSCF complex, and therefore expensive.
Third, the SIP message header parameters such as Call-ID, branch, and tag cannot always be relied upon for uniqueness and randomness while, at the same time, also bearing distinctive properties in the substring portions to identify a call session. This is because if the substrings of the random parameter value strings are used as common substrings and mixed with other random strings of the SIP header parameters, then the overall entropy of the SIP header parameter strings is destroyed, leading to a higher probability of collisions at the routing framework. This leads to misrouting of the messages, especially under high call volume, as the probability of collisions rises with the number of messages. Thus, the use of common substrings of SIP message header parameters in a manner that renders the SIP header values collision-prone violates the randomness requirements of RFC3261. Also, such a scheme may not work at all when the variants/extensions of RFC3261 are to be supported, especially along with the pure RFC3261-based signaling within the same call session. The variants and extensions of the SIP standard could place additional constraints on the various parameter values, or could modify the existing constraints (per RFC3261), or could use the parameter values for a totally non-standard purpose.